Linux fd 系列|信号编程(signal)竟能这样做?涨姿势
信号是什么?
平台声明:
Linux 操作系统
首先说,信号(signal)是什么?
信号( signal )本质是 Linux 进程间通信的一种机制,也叫软中断信号。既然是通信机制,那么就是传递信息用的,信号传递的信息很简单,就是一个整数,一般用于配合系统管理任务,比如进程的终结、恢复、热加载等。
信号都用整数常量表示,命名以 SIG 为前缀,比如 SIGINT( ctrl-c 触发),SIGKILL( kill -9 触发 )。
信号一般怎么产生?
由内核产生,比如内存错误,除 0 等错误,内核通过信号通知到相应的进程; 可以由其他进程传递给目标进程,比如 kill 命令就是专门干这个事情的;
信号处理分为两个阶段:
发送阶段:内核将信号(signal)放到对应的 pending 队列中; 传递阶段:也叫做处理阶段,内核将信号从 pending 队列中取出来,并且进行处理,一般是调用相应的回调函数(处理方式有三种:用户定义、内核默认定义 SIG_DEL、忽略 SIG_IGN);
signalfd 是什么?
了解了什么是信号( signal ),那 signalfd 又会是什么呢?
是一个跟信号关联的文件描述符,能够以 io 的行为获取到系统信号,属性上来讲 signalfd 也是一个匿名 fd 类型。
signalfd 长什么样子?
奇伢按照 man signalfd
里面的例子,写了个 demo,跑在 Linux 机器上,按照惯例去看下 fd 的样子。
root@ubuntu:~# ll /proc/15445/fd
lrwx------ 1 root root 64 Aug 24 16:42 3 -> anon_inode:[signalfd]
root@ubuntu:~# cat /proc/15445/fdinfo/3
pos: 0
flags: 02
mnt_id: 11
sigmask: 0000000000000006
从这里可以得到简单的信息:
signal 用的匿名 inode ,signalfd 属于匿名 fd 的一种; 句柄关联的重要信息就是 sigmask,通过 /proc/${pid}/fdinfo/3
能看到这个值;
signalfd 使用姿势?
其实信号是很讲究的,甚至有信号编程一说,Linux 的 signalfd 为信号的处理提供了一种新的方法,统一到文件的 io 模式,契合一切接文件的理念。
系统调用:
#include <sys/signalfd.h>
int signalfd(int fd, const sigset_t *mask, int flags);
该系统调用返回一个整数类型 signalfd,这个句柄跟信号行为绑定,当发生信号的时候,句柄触发可读事件。
第一个参数也可以传入一个有效的信号 fd 的句柄,如果传入的是 -1 ,那么内核会自动创建一个新的 fd 。
完整的代码例子,在 Linux 机器上,通过 man signalfd
就可以获取到。
// 信号清零
sigemptyset(&mask);
// 添加信号到掩码集
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGQUIT);
// 设置该进程为对应的信号集的内容(当前已经的信号集合做并集、交集、覆盖)
// 这行代码才是真正的信号设置;
sigprocmask(SIG_BLOCK, &mask, NULL)
// 创建 signalfd 句柄(绑定信号)
sfd = signalfd(-1, &mask, 0);
for (;;) {
// 读取 signalfd 数据(数据代表信号)
s = read(sfd, &fdsi, sizeof(struct signalfd_siginfo));
// ...
// 信号的逻辑处理
}
上面的例子,signalfd 没有信号(没有可读事件)的时候会阻塞在 read
调用上,运行效果如下:
root@ubuntu:~/temp# ./a.out
^CGot SIGINT
^CGot SIGINT
^CGot SIGINT
可以看到每一次 ctrl + c
触发的信号被捕捉到,并且打印出来。用文件 io 的方式来接收信号,牛。
怎么做到的呢?照例,我们浅析一下内核的代码,位于 fs/signalfd.c
,这是一个很小的文件,正是这个文件完成了对信号“文件化”的封装。
上面最重要的两个调用:
sigprocmask
:设置当前进程的信号掩码,把SIGINT
,SIGQUIT
处理屏蔽掉,关闭内核默认行为;signalfd
:获取到一个和信号关联的“文件”句柄;
signalfd 原理剖析
环境声明:
Linux 内核版本 4.19
SYSCALL_DEFINE3(signalfd, int, ufd, sigset_t __user *, user_mask, size_t, sizemask)
{
return do_signalfd4(ufd, &mask, 0);
}
static int do_signalfd4(int ufd, sigset_t *mask, int flags)
{
struct signalfd_ctx *ctx;
// 如果是 -1,内核创建;
if (ufd == -1) {
//
ctx->sigmask = *mask;
// 获取一个匿名句柄;
ufd = anon_inode_getfd("[signalfd]", &signalfd_fops, ctx, O_RDWR | (flags & (O_CLOEXEC | O_NONBLOCK)));
} else {
// 校验传入的句柄是否合法
struct fd f = fdget(ufd);
ctx = f.file->private_data;
if (f.file->f_op != &signalfd_fops) {
return -EINVAL;
}
// 覆盖设置新的值
ctx->sigmask = *mask;
// 唤醒阻塞在当前进程的信号等待队列
wake_up(¤t->sighand->signalfd_wqh);
}
return ufd;
}
{
return do_signalfd4(ufd, &mask, 0);
}
static int do_signalfd4(int ufd, sigset_t *mask, int flags)
{
struct signalfd_ctx *ctx;
// 如果是 -1,内核创建;
if (ufd == -1) {
//
ctx->sigmask = *mask;
// 获取一个匿名句柄;
ufd = anon_inode_getfd("[signalfd]", &signalfd_fops, ctx, O_RDWR | (flags & (O_CLOEXEC | O_NONBLOCK)));
} else {
// 校验传入的句柄是否合法
struct fd f = fdget(ufd);
ctx = f.file->private_data;
if (f.file->f_op != &signalfd_fops) {
return -EINVAL;
}
// 覆盖设置新的值
ctx->sigmask = *mask;
// 唤醒阻塞在当前进程的信号等待队列
wake_up(¤t->sighand->signalfd_wqh);
}
return ufd;
}
看一下 signalfd 支持的接口调用:
static const struct file_operations signalfd_fops = {
.show_fdinfo = signalfd_show_fdinfo,
.poll = signalfd_poll,
.read = signalfd_read,
// ...
};
通过这个可以知道 signalfd 支持的特性:
支持 /proc/${pid}/fdinfo/xx
查看信息( 对应signalfd_show_fdinfo
函数 );支持 read,close 调用 ( 对应 signalfd_read
函数 );支持 poll 调用,支持 epoll 管理( 对应 signalfd_poll
函数 );
这个函数做的事情非常简单,就是把等待对象挂到当前进程的信号结构的链表上。表头是:current->sighand->signalfd_wqh
,这个就有意思了,这里直接挂到当前进程的结构上。换句话说,唤醒也是自此表头开始。
回忆一下 timerfd ,是挂在 timerfd_ctx->wqh
的字段上。这里的差别是因为信号是对进程来说的。
读一个 signalfd 的操作非常简单,主要逻辑:
查看当前队列中是否有信号,有的话就取出来,填充到用户给的结构体中; 如果句柄是阻塞类型的,在没有信号的时候,会切走 cpu,等到有信号的时候切回来。如果是非阻塞类型的,直接报错,返回 EAGAIN ;
简要的代码注释如下:
static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
// read 数据的存放结构体
siginfo = (struct signalfd_siginfo __user *) buf;
do {
// 取出信号队列中的一个信号,填充好 info 结构体
ret = signalfd_dequeue(ctx, &info, nonblock);
// 循环操作,填充用户指定个数的信号
ret = signalfd_copyinfo(siginfo, &info);
// ...
} while (--count);
return total ? total: ret;
}
static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info, int nonblock)
{
// 取出一个信号
ret = dequeue_signal(current, &ctx->sigmask, info);
// 如果没有 pending 的信号,就看是否是非阻塞请求,非阻塞请求就报错跳出;
// 阻塞请求就继续往后走
// 把当前位置加入到信号唤醒地方(这样后续有信号的时候,能够立马切回来)
add_wait_queue(¤t->sighand->signalfd_wqh, &wait);
for (;;) {
// 取信号
ret = dequeue_signal(current, &ctx->sigmask, info);
// 判断是否还有 pending 的信号;
if (signal_pending(current)) {
}
// 让出 cpu,调度切走
schedule();
}
// 把当前进程从 signalfd_wqh 摘掉
remove_wait_queue(¤t->sighand->signalfd_wqh, &wait);
}
这里就能非常清晰的看到,进程有信号的时候,signalfd 句柄就是可读的。
signal 和 epoll 的配合
epoll_ctl
注册 signalfd 的时候,调用 signalfd_poll
,signalfd_poll
会把 epoll 创建的 wait entry 挂到 current->sighand
上。唤醒的时候调用这个 wait 链表的回调。
唤醒的操作其实不在 signalfd.c 文件中,而是在原有的信号软中断的流程中。
在内核函数 signalfd_notify
中,会判断进程的 sighand->signalfd_wqh
是否非空,如果非空,说明有人关注这个信号,那么就会通知到对应的 waiter 。
为了知识的完整性,说个点,signalfd_notify
其实在 timer 定时器的流程中也有调用,但跟我们本次主干没啥关系,这里忽略。
信号的发送唤醒的简要示意图:
所有的信号发送都会调用到 send_signal
,在这个里面实现了唤醒 sighand->signalfd_wqh
链表的操作。从而使得 epoll 感知到 signalfd 可读了(因为来信号了),使得 epoll 从 epoll_wait 出唤醒,然后调用 read 操作,把信号的相关信息从句柄中读出来。
signalfd_notify
-> wake_up (唤醒等待队列,也就是 epoll)
-> ep_poll_callback
划重点:唤醒在信号发送的过程。
总结
信号能够像文件一样 read 出来,这种优雅的信号处理方式得益于 signalfd 的封装; 信号是挂在在进程 task_struct 结构体上的,信号队列非空的时候 signalfd 句柄可读; 和 epoll 池的配合同样还是老套路,epoll_ctl 注册的时候调用 .poll
接口挂载 epoll 的 wait entry 到sighand->signalfd_wqh
之上,信号发送时调用 signalfd_notify 唤醒 epoll ;signalfd 也是一种匿名 fd 类型;
后记
一切皆文件,又学到一个句柄类型。
~完~
往期推荐
往期推荐
坚持思考,方向比努力更重要。关注我:奇伢云存储